home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / tex-k-archive.gz / tex-k-archive / 000814_lembark@wrkhors.la.ca.us_Fri Jul 29 16:50:10 1994.msg < prev    next >
Internet Message Format  |  1994-10-11  |  4KB
  1. Received: from gate.oxy.edu by cs.umb.edu with SMTP id AA03741
  2.   (5.65c/IDA-1.4.4 for <tex-k@cs.umb.edu>); Sat, 30 Jul 1994 08:41:19 -0400
  3. Received: from bengal.oxy.edu (bengal.oxy.edu [134.69.1.3]) 
  4.     by gate.oxy.edu (8.6.9/8.6.9) with ESMTP id FAA26401 
  5.     for <tex-k@cs.umb.edu>; Sat, 30 Jul 1994 05:41:17 -0700
  6. Received: (from uucp@localhost) 
  7.     by bengal.oxy.edu (8.6.9/8.6.9) with UUCP id FAA10480 
  8.     for tex-k@cs.umb.edu; Sat, 30 Jul 1994 05:41:17 -0700
  9. Received: from workhorse  (wrkhors.la.ca.us [127.0.0.1])
  10.            by wrkhors.la.ca.us (8.6.9/8.6.9) with ESMTP
  11.            id XAA22058 for <tex-k@cs.umb.edu>;
  12.            Fri, 29 Jul 1994 23:50:11 -0700
  13. Message-Id: <199407300650.XAA22058@wrkhors.la.ca.us>
  14. To: tex-k@cs.umb.edu
  15. Subject: probable bug in web2c-6.1 `mf' distribution compiled on linux
  16. Date: Fri, 29 Jul 1994 23:50:10 -0700
  17. From: Steven Lembark <lembark@wrkhors.la.ca.us>
  18.  
  19.  
  20. Problem: the high-order byte is either getting lost or zeroed before 
  21. writing to .tfm files by mf.  This problem has persisted after six re-makes
  22. of mf using gcc-2.5.8 and 2.6.0, mf-1.0 and mf-1.1 and the new autoconf to
  23. try an re-generate the configure scripts.
  24.  
  25. Symptom: mf "\mode=CanonCX; input <pick one>" gives a normal-looking
  26. execution, creates a normally sized .tfm file, and exits.  Running TeX
  27. using this .tfm file gives a run-time error of invalid file format.
  28.  
  29. Likely Cause:  Whatever routine is supposed to write the file size to 
  30. bytes 0 & 1 of the .tfm file is either zeroing or dropping a bit on write.
  31.  
  32. Running "od -x" on a clean file from the ctan archives 
  33. and a local file then diff-ing them gives one difference: line 0 offset 1.
  34. On my system this is the high-order byte [whatever the TFtoPL doc's may say,
  35. these bytes are stored with the low-order byte first].
  36.  
  37. For example "od -x $FROM_THE_ARCHIVE/pnr10.tfm | head -1" gives:
  38.  
  39.    0000000 da01 1200 0000 7f00 4e00 0900 0400 0100
  40.  
  41. $FROM_MY_MF/pnr10.tfm | head -1 gives:
  42.  
  43.    0000000 da00 1200 0000 7f00 4e00 0900 0400 0100
  44.  
  45. and diff $CTAN_FILE $HOMEGROWN_FILE on the od -x results gives:
  46.  
  47.   1c1
  48.   < 0000000 da01 1200 0000 7f00 4e00 0900 0400 0100
  49.   ---
  50.   > 0000000 da00 1200 0000 7f00 4e00 0900 0400 0100
  51.  
  52. this only difference between the two is "01" vs. "00" in line 1 offset 1.
  53. the actual file size for ctan's pnr10.tfm is 1896 bytes, or 474 words (0x01da).
  54. the actual file size of the homegrown pnr10.tfm is the same, 1896 bytes.
  55.  
  56. The following routine will fix the homegrown .tfm file:
  57.  
  58.     while( --argc )
  59.     {
  60.         FILE *in = fopen( *++argv, "r+b" );
  61.         if( in != (FILE *)NULL )
  62.         {
  63.             short i;
  64.             char *a = (void *)&i;
  65.  
  66.             fseek( in, 0, SEEK_END );
  67.  
  68.             i = ftell( in ) / 4;
  69.  
  70.             rewind( in );
  71.             fwrite( a+1, 1, 1, in );
  72.             fwrite( a  , 1, 1, in );
  73.         }
  74.         fclose( in );
  75.     }
  76.  
  77. Thus: writing the file size in reverse order to what the TFtoPL doc's say is
  78. correct fixes the .tfm.
  79.  
  80. I have no idea whatsoever how to read, test or fix web files, else I'd at least
  81. try to send a fix.  A few grep's on the web2c/mf/*.c files didn't give anything
  82. obvious, so I've admitted defeat on this one.  For now at least I can patch
  83. the .tfm files by writing the corrected size back into the file.
  84.  
  85. Interesting note: the *.*gf files seem to be clean, since *.*pk files generated
  86. via gftopk work nicely.  It's only the .tfm files that seem messed up.  TeX is
  87. happy enough -- it generates pretty output from the cleaned up .tfm files; 
  88. dviljk compiled for my laserjet-IIp also generates useful output from the .tfm
  89. and .*pk files.
  90.  
  91.  
  92. environment:
  93.  
  94.   Linux workhorse 1.1.0 #4 Wed May 25 23:32:35 PDT 1994 i486
  95.   gcc-2.5.8 and gcc-2.6.0 (both give same results)
  96.   GNU Make version 3.71, by Richard Stallman and Roland McGrath.
  97.   GNU m4 1.1
  98.   Autoconf version 1.11
  99.  
  100.  
  101. Steve Lembark                       Workhorse Computing
  102. (lembark@wrkhors.la.ca.us)          1118 S. Valencia Ave., #319, 90015-2087
  103. -----------------------------------------------------------------------------
  104.  The opinions expressed here are those of this company.  I own the company.
  105. -----------------------------------------------------------------------------